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(54) Smart bookmarks for small footprint device applications 



(57) Users of snnall footprint devices such as smart 
cellular phones, personal data assistants, etc. may cre- 
ate and store bookmarks referencing various types of 
objects and/or data sources. Each bookmark may com- 
prise a Uniform Resource Locator (URL) which may be 
used to refer to the object/data source. The bookmark 
system may be open-ended, allowing virtually any type 
of object or data source to be bookmarked. The book- 
marks may later be used by a user or application to ref- 
erence the respective data source to perform some type 



of action on the data, source, such as displaying or edit- 
ing it. A lightweight application/service containment 
framework is described which enables services to run 
on small footprint devices. A bookmark service may 
cooperate with an activation framework capable of 
encapsulating various types of entities. In one embodi- 
ment, a bookmark service operates in conjunction 
together with the JavaBeans™ Activation Framework 
(JAR) to implement the bookmark functionality. 
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Description 

BACKGROUND OF THE INVENTION 

1 . Held of the Invention 



[0001] This invention relates generally to computer application programs and small footprint devices. More partic- 
ularly, the invention comprises a system and method for bookmarking various types of data source objects for use by 
applications and services running on a small footprint device. 

2. Description of the Relevant Art 

[0002] The field of "smarT small footprint devices is growing and changing rapidly. Small footprint devices include 
handheld computers, personal data assistants (PDAs), cellular phones, global positioning system (GPS) receivers 
game consoles, and many more such devices. These devices are becoming more intelligent and interconnected. Tech- 
nologies such as JinP" from Sun Microsystems, Inc. and initiatives such as the Open Service Gateway Initiative (OSGi) 
are expanding the traditional concepts of computer networi<s to include small footprint devices. 

[0003] This increased device interconnection has introduced a need for both new types of computing services and 
new ways to integrate computing services, both inter-device-based and intra-device-based services. A "service" is an 
entity implemented within or accessible from a device that can be used by a person, an application, oranother service 
The concept of a service Is broad and can be considered at many different scales. For example, services include famil- 
iar network-based services such as shared printing, email, telephony, etc. Services also include less familiar examples 
such as an energy management service which may control the power consumption of devices within a local network a 
diagnostic service which allows a device to send information to a service technician when an error occurs, a health- 
monitoring service which immediately notifies health professionals of an emergency, etc. 

[0004] Sen^ices also include modules or applications located and executable within a local machine or device For 
example, local application programs may utilize a service to communicate with an HTTP server, an HTML render 
engine service, a bookmari< service, a user interface service, etc. In this example, an application program may use 
these services together to implement a web browser program. 

[0005] It is becoming more common today to execute multiple services and applications together in a single small 
footpnnt device. However, since memory, processing power, and other resources are typically very limfted in small foot- 
print devices, a specialized lightweight service/application containment frameworic is necessary to achieve the desired 
integration of services and applteations. It is also desirable that the containment f ramewori< be flexible and extendable 
enough to provide a framework for any types of services and applications for any kind of small footprint device. A further 
goal may be that the containment framework be compatible and integrated with off-device services such as services 
available to devices in a Jini™ networic The containment framework described herein achieves the above-stated goals. 
[0006] The lightweight containment framework may enable small footprint devices such as personal data assist- 
ants, smart cellular phones, etc. to run the types of multi-purpose application programs traditionally associated with 
desktop computing environments. For example, the Personal Applications suite available from Sun Mbrosystems Inc 
IS built around one embodiment of the containment framework. The Personal Applications suite comprises an Inte- 
grated set of compact, memory-efficient applications, including the Personal Applications Browser, the Personal Appli- 
cations Email Client, and the Personal Organizer. 

[0007] As these types of applications become available for small footprint devices, it becomes increasingly desira- 
ble to provide a general mechanism to integrate and abstract entities, objects, and data sources used by or imple- 
mented in various applications or senrices. One approach for enabling this type of abstraction and integration Is to 
enable a bookmark service to provide a persistent reference to any of various types of entities, objects, arid data 
sources which may be created or used in application programs or sen/ices. For example, a user may bookmaric a par- 
ticular piece of email or a particular contact entry from a contact list for convenient reference later. 
[0008] Enabling this type of bookmark system is particularly desirable within a small footprint device environment 
Such a system may significantly reduce the level of difficulty involved in performing particular operations, since the 
means for user input on a small footprint device are often very Rmited. However, implementing this type of bookmari< 
system is also a particular challenge for a small footprint device environment, since a certain level of software infrastruc- 
ture IS necessary to achieve the desired abstraction and generality, yet the software infrastructure must be sufficientV 
lightweight to run on a small footprint device. A system and method for implementing this type of bookmark system for 
a small footprint device is described herein. 
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SUMMARY OF THE INVENTION 

[0009] Particular and preferred aspects of the invention are set out in the acconnpanying independent and depend- 
ent claims. Features of the dependent claims may be combined with those of the independent claims as appropriate 

5 and in combinations other than those explicitly set out in the claims. 

[0010] The present invention enables small footprint dev'ce users to create and store bookmarks referencing vari- 
ous types of objects and/or data sources (collectively referred to herein as data sources). Each bookmark may com- 
prise a Uniform Resource Locator (URL) which may be used to refer to the object/data source. The bookmark system 
may be open-ended, allowing virtually any type of object or data source to be bookmarked. The bookmarks may later 

10 be used by a user or application to reference the respective data source to perform some type of action on the data 
source, such as displaying or editing it 

[0011] For example, a user may bookmark a particular piece of email from within an email client. In this case, the 
bookmark may reference some type of encapsulating object, referred to as a data source, which comprises data repre- 
senting the email. Thus, the bookmark service may cooperate with an activation framework capable of encapsulating 

15 various types of entities. The activation framework may assign a type to a data source which distinguishes it from other 
kinds of data sources. The activation framework may also allow particular "verbs" to be associated with a data source 
type, and a particular executable module or routine may be associated with a data source type and verb, where the exe- 
cutable module may be invoked to perform the action designated by the verb for a particular data source. 
(0012) A bookmark service module executes within an application/service containment framework of a smalt foot- 

20 pmt ctevtce. which may be invoked by other applications/services in order to create and store a bookmark referencing 
a parteuiar data source. A lightweight application/service framework for small footprint devices is described below. The 
bookmafk service may operate in conjunction with an activation framework, as described above. In one embodiment, 
tne bookmark service operates in conjunction together with the JavaBeans™ Activation Framework (JAF) to implement 
tt>« described function alrty. 

BRIEF DESCRI PTION OF THE DRAWINGS 

[0013] Other objects and advantages of the invention will become apparent upion reading the following detailed 
description and \jpon reference to the accompanying drawings in which: 

30 

Figure 1 is a block diagram illustrating various types of data sources whk:h may be bookmarked; 

Figure 2 is a flowchart diagram illustrating the process of creating a bookmark referencing a particular data source; 

35 Rgure 3 is a flowchart diagram illustrating the process of using a bookmark to reference a respective data source; 

Figure 4 is a block diagram illustrating the major elements comprising the JavaBeans™ Activation Framework archi- 
tecture: 

4o Figure 5 is a block diagram illustrating the hardware archrtecture of a typical smalt footprint device; 

Figure 6 illustrates a typical hierarchy of hardware/software layers involved in a system running applications and 
sen/ices within the containment framework; 

45 Figure 7 illustrates an exemplary network in which a small footprint device running applications/services in the con- 

tainment framework is connected to a local service-based network; 

Figure 8 illustrates the discovery process, in which a service provider finds a lookup service; 

50 Figure 9 illustrates the join process, in which a service provider registers its service with a lookup service; 

Figure 1 0 illustrates the lookup process, in which a client requests a service from a lookup service; 

Figure 1 1 illustrates the sen/ice invocation process, in which a client invokes a service using a service object 
55 received from a lookup sen/ice; 

Figure 12 is an abstract block diagram illustrating the basic architecture of the containment framework; 



3 
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Figures 13 and 14 illustrate the use of module request listeners in the containment framework to simulate a hierar- 
chical containment environment; 

Rgure 15 illustrates the use of parcels to group modules together; 

Rgure 1 6 is a flowchart diagram illustrating a typical lookup process that the central framework instance may per- 
form when it receives a lookup request for a service module from a client module; and 

Rgure 1 7 is a flowchart diagram Illustrating the module release process 

10 

[0014] While the invention is susceptible to various modifications and alternative forms, specific embodiments 
thereof ^^e shc^u by way of example in the drawings and are herein described in detail. It should be understood how- 
ever, ftat the drawings and detailed description thereto are not intended to limit the Invention to the particular for;n dis- 
Closed, birt on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the 
IS scope of the present invention as defined by the appended claims. 

DETAILED DESCRIPTION OF THE PRFFERRED EMBQDlMENTg 

Figure 1 - Data Source Examples 

20 

[00151 Figure 1 illustrates some examples of data sources which may be bookmarked. As described above the 
booknr,ari< service may operate in conjunction with an open activation framework allowing various types of data sou'rces 
to be typed and encapsulated. Rgure 1 illustrates some exemplary types of data sources which users of typical appli- 
cation programs running on a small footprint device m^ wish to bookmark 

[OOiq As illustrated in Rgure 1 . a user may bookmark a particular piece of email. For example, the user may select 
a particular command wrtiile reading an email which creates a bookmark for the email. The user may later quickly refer 
to the email using the bookmari<. For example, the user may invoke a bookmartc service which displays a list of book- 
mark. Rgure 1 shows other data sources whteh may be bookmarked. such as a web page bookmariced from within a 
web browser and an appointment entry bookmariced from within a personal Information manager program 
[0017] Bookmarks may be organized in various ways. For example, a system may have a central list where all book- 
marks are kept, or separate applications may have their own bookmartc lists, or various combinations of these 
approaches may be taken. The request to create a bookmark may occur in various situations, such as Im/oking a book- 
maric service and selecting a data source to bookmark, or issuing a command from within an application which invokes 
a bookmark service, etc. In one embodiment, bookmarks may be imported from another system 
[0018] The bookmarics of Rgure 1 may reference local or remote data sources. For example, the web page book- 
mark shown may reference an HTML page stored on a remote server, or the email bookmartc shown may reference an 
email stored on another system. 
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Rgure 2 - Creatino a Bookmark 

[0019] Rgure 2 is a flowchart diagram illustrating the process of creating a bookmark referencing a particular data 
source It .s noted that Rgure 2 illustrates one embodiment of the bookmartc creation process. Other embodiments are 
possible in which vanous steps are added, combined, modified, or omitted 

m^uVnml?rt "^^"^ !' "^^^ """"^^ ^ bookmark service. For example, a user may issue a pulldown 

menu comrr^and to invoke a bookmartc service, and a graphical user interface for the bookmartc service may then 
appear on the display. In step 602. the user selects a particular data source to bookmark. For example, the user may 
browse through a directory structure to find a file comprising a particular type of data source, such as a virtual business 
card, an .mage, etc^ Step 600 and step 602 may be combined into a single step. For example, the user may issue a 
command from wrthin an application which instructs the bookmark service to bookmark a currently selected data 



SO source 



S°n?Vl K ^'^P,^°^' bookmark service creates a bookmark entry referencing the data source selected in step 
602^ The bookmark entry comprises infonnation which identifies the particular data source selected in step 602. In one 
embodiment the bookmark entry comprises a URL. 

pSim Jt^tSf K ' """"^^^ ^^'^''^e *be bookmark entry created in step 604. For example, in one 

Tr^ilT! i H . ""^ ^"'^"^ ^ °' bookmarics which is accessible from the bookmartc 

service rtsetf and also accessible from other applications running in the system. In another embodiment, the system 
may maintain separate bookmartc lists for different applications or data source types. 
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Figure 3 - Referencing a Bookmarked Data Source 

[0023] Figure 3 is a flowchart diagram illustrating the process of using a booknnark to reference a respective data 
source, it is noted that Figure 3 illustrates one embodiment of the process of referencing a bookmark. Other embodi- 

5 ments are possible in which various steps are added, combined, modified, or omitted. 

[0024] In step 610 the user selects a bookmark entry. The bookmark selection may occur in various situations. For 
example, the user may invoke a bookmark service and select a particular bookmark entry from a list presented to the 
user by the bookmark service. The user may also select a particular bookmark from within an application, e.g., by 
selecting a particular menu item from a bookmark menu. 

10 [0025] In step 612 the user selects an action to perform on the data source referenced by the bookmark entry 
selected in step 610. For example, a user may select an "edlT action for a bookmarked email, or a "view" actton for a 
bookmarked image, etc. The user may select the action to perform by selecting from a list of possible actions, or the 
action to perfomri may be implicit from the context of the user's actions. 

[0026] in step 614 an appropriate program module is invoked in order to perform the action specified in step 612 
15 on the data source referenced by the bookmark entry selected in step 610. Steps 612 and 614 assume that an activa- 
tion framework is present which enables actions to be defined for data source types and enables particular program 
modules to be mapped to those actions. In one embodiment, the bookmark service and/or application programs run- 
ning within a small footprint device utilize the JavaBeans™ Activation Framework (JAF) to implement steps 612 and 61 4. 
The JavaBeans™ Activation Framework is described below. 
20 [0027] Steps 61 0, 61 2, and 61 4 may be combined into a single step. For example, a user may access a menu from 
within a personal contact list service which displays a list of bookmarked personal contact entries. A user may then 
choose a contact entry from the menu, which causes the application to display the contact entry. 

JavaBeans^ Application Framework 

25 

[0028] In one embodiment, the JavaBeans™ Activation Framework (JAF) is utilized to provide the infrastructure to 
encapsulate data sources, define actions for data sources, etc. This Section describes the JavaBeans™ Activation 
Framework. 

[0029] The JAF implements several related .services including: determining the type of arbitrary data, encapsulating 
30 access to data, discovering the operations available on a particular type of data, and instantiating the software compo- 
nent that corresponds to the desired operation on a particular piece of data. The JAF is packaged as a Standard Exten- 
sion to the Java™ platform. 

[0030] Figure 4 illustrates the major elements comprising the JAF architecture. Note that the framework shown here 
is not bound to a particular application. 
35 [0031] The DataHandler class shown in Figure 4 provides a consistent interface between JAF-aware clients and 
other subsystems, 

[0032] The DataSource interface encapsulates an object that contains data, and that can retum both a stream pro- 
viding data access, and a string defining the MIME type describing the data. Classes can be implemented for common 
data sources (vyeb, file system, IMAP, ftp etc.). The DataSource interface can also be extended to allow per data source 
40 user customizations. Once the DataSource is set in the DataHandler, the client can detemnine the operations available 
on that data. 

[0033] The JAF includes two DataSource class implementations for convenience: FileDataSource accesses data 
held in a file. URLDataSource accesses data held at a URL. 

[0034] The CommandMap provides a service that allows consumers of its interfaces to detemiine the 'commands' 
45 available on a particular MIME Type as well as an interface to retrieve an object that can operate on an object of a par- 
ticular MIME Type (effectively a component registry). The Command Map can generate arid maintain a list of available 
capabilities on a particular data type by a mechanism defined by the implementation of the particular instance of the 
CommandMap. 

[0035] The JavaBeans™ package provides the programming model for the software components that implemented 
50 the commands. Each JavaBeans™ component can use extern alization, or can implement the CommandObject inter- 
face to allow the typed data to be passed to it. 

[0036] The JAF defines the CommandMap interface, which provides a flexible and extensible framework for the 
CommandMap. The CommandMap interface allows developers to develop their own solutions for discovering which 
commands are available on the system. A possible implementation can access the *types registry' on the platform or 
55 use a server-based solution. The JAF provides a simple default solution based on RFC 1524 (.mailcap) like functional- 
ity. 

[0037] Beans extend the CommandObject interface in order to interact with JAF services. JAF-aware JavaBeans™ 
components can directly access their DataSource and DataHandler 
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objects in order to retrieve the data type and to act on the data. 
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Using the JAF Framework 

[0038] The 'canonical' consumer of the JAF framework accesses it through the DataHandler (although the major 
subsystems are designed to also operate independently). An undertying DataSource object is associated with the Data- 
Handler when the DataHandler class is constructed. The DataHandler retrieves the data typing information from the 
DataSource or gets the data type directly from the constructor. Once this initialization step is complete, request a list of 
commands that can be perfomried on the data item can be accessed from the DataHandler. 

[0039] When an application issues a request for this list, the DataHandler uses the MIME data type specifier 
returned, m order to request a list of available commands from the CommandMap object The CommandMap has 
knowledge of available commands (implemented as Beans) and their supported data types. The CommandMap retums 
a subset of the full list of all commands based on the requested MIME type and the semantics of the CommandMap 
implementation, to the DataHandler. 

[0040] Ultimately when the application wishes to apply a command to some data, it is accomplished through the 
appropnate DataHandler interface which uses the CommandMap to retrieve the appropriate Bean which is used to 
operate on the data. The container (user of the framework) makes the association between the data and the Bean. 

JAF Usay Scenarios 



[0041] This scenario uses the example of a hypothetical file viewer application in order to illustrate the normal flow 
of tasics involved when implementing the JAF. The file viewer is similar to CDE's 'dtfile,' or to the Windows 95 Explorer 
utifity W>en teufKhed. it presents the user with a display of available files. It includes a function like CDE's dtfile or 
Explorer^ -ngfr mouse* menu, where all operations that can be perfomned on a selected data item are listed in a popup 
25 menu tof thai item k k k 

[00421 A typcal user launches this application to view a directory of files. When the user specifies a file by cftcking 
on it the application displays a popup menu which lists the available operations on that file. Rle system viewer utilities 
nomnaiy tndude 'edit.* View,' and 'print commands as available operations. For instance selecting View' causes the util- 
ity to open the selected file in a viewer which can display data of the data type held in that file. 
[00431 Descriptk>n of tasks performed by the application is broken down into three discrete steps, for clarity: 

Inmalizatkxi: The application constructs a view of the file system. 

Getting the Command List: The application presents the command list for a selected data item. 
Performing the Command: The application performs a command on the selected data object. 

Initialization 

[0044] One of the interfaces mentioned below is the 'DataSource' object. The DataSource object encapsulates the 
underlying data object in a class that abstracts the underlying data storage mechanism, and presents its consumers 
with a common data access and typing interface. The file viewer application queries the file system for its contents 
[0045] The viewer instantiates a DataSource object for each file in the directory. Then it instantiates a a DataHan- 
dler with the DataSource as its constructor argument. A DataHandler cannot be instantiated without a DataSource The 
DataHandler object provides the client application with access to the CommandMap, which provides a service that ena- 
bles access to commands that can operate on the data. The application maintains a list of the DataHandler objects, 
queries them for their names and icons to generate its display. 

// for each file in the directory: 
File file - new File (f ile^name) ; 
DataSource ds - new FileDataSource (file) ; 
DataHandler dh - new DataHandler (ds) ; 



55 
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Getting the Command List 

[0046] Once the application has been inrtialized and has presented a list of files to the user, the user can select a 
file on the list. When the user selects a file, the application displays a popup menu that lists the available operations on 
5 that file. 

[0047] The application implements this functionality by requesting the list of available commands from the Data- 
Handler object associated with a file. The DataHandler retrieves the MIME Type of the data from the DataSource object 
and queries the CommandMap for operations that are available on that type. The application interprets the list and 
presents it to the user on a popup menu. The user then selects one of the operations from that list 

70 

// get the command list for an object 

Comniandlnfo caidlnfod « dh. getPref erredCommands ( ) ; 

PopupMenu popup « new PopupMenu (* Item Menu* ) ; 

// populate the popup with available commands 
ford - 0; i < cmdinfo . length; i-^+) 

20 

popup, add (cmdinfo (il -getCommandName ( ) ) ; 

// add and show popup 
add (popup); 

PS 

popup . s how ( x_pos , yjpo s) ; 



30 

Performing a Command 

[0048] After the user has selected a command from the popup menu, the application uses the appropriate Com- 
mand Info class to retrieve the Bean that corresponds to the selected command, and associates the data with that Bean 
35 using the appropriate mechanism (DataHandler, Extemalization etc.). Some CommandObJects (viewers for instance) 
are subclassed from java.awt.Component and require that they are given a parent container. Others (like a default print 
Command) might not present a user interface. This allows them to be flexible enough to function as stand atone 
viewer/editors, or perhaps as components In a compound document system. The •application' is responsible for provid- 
ing the proper environment (containment, life cycle, etc.) for the CommandObject to execute in. 

40 

// get the command object 

ObjecTL cmdSean - cmdinfo [cad_id] . get CommandObject (dh, 

this . getClassLoader () ) ; 
... // use serializaticn/externalization where ■ appropriate 
rny_awc_container . add ( (Component ) cmdBean) ; 



45 



An Atternative Scenario 

[0049] The first scenario was the 'canonical' case. There are also circumstances where the application has already 
55 created objects to represent its data. In this case creating an in-memory instance of a DataSource that converted an 
existing object into an InputStream is an inefficient use of system resources and can result in a loss of data fidelity. 
[0050] In these cases, the application can instantiate a DataHandler, using the DataHandIer(Object obj, String 
mime Type) constructor. DataHandler implements the Transferable interface, so the consuming Bean can request rep- 
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resentations other than InputStreams. The DataHandler also constructs a DataSource for consumers that request it 
The DataContentHandler mechanism is extended to also allow conversion from Objects to InputStreams. 
[0051] The following code is an example of a data base front end using the JAR which provides query results in 
terms of objects. 

/*- 

* Get the viewer to view my- query results; 
*/ 

Component getQueryViewer (QueryObj ect qo) thro%#s Exception ( 
String mime^type - qo.getType ( ) ; 
Object q^resuit - qo ,getResultObject {) ; 

DataHandler my_dh - new DataHandler (q^resuit, mime_type) ; 

return (Coii^onent)my_dh.getCoinmand("vieW) .getCoinmandObject (my_dh, 
null}); 

} 



JAF Framework Core Classes 
[0052J 

interface DataSource: The DataSource interface provides the JavaBeans™ Activation Framework with an abstrac- 
tion of some arbitrary collection of data. It provides a type for that data as well as access to tt in the form of Input- 
Streams and OutputStreams where appropriate. 

class DataHandler: The DataHandler class provides a consistent interface to data available in many different 
sources and formats. It manages simple stream to string conversions and related operations using DataCon- 
tentHandlers. It provides access to commands that can operate on the data. The commands are found using a 
CommandMap. " 

interface DataContentHandler: The DataContentHandler interface is implemented by objects that can be used to 
extend the capabilities of the DataHandler-s implementation of the Transferable interface. Through DataCon- 
tentHandlers the framework can be extended to convert streams in to objects, and to write objects to streams. 

interface DataContentHandlerFactory: This interface defines a factory for DataContentHandlers. An implementa- 
tion of this interface should map a MIME type into an instance of DataContentHandler. The design pattern for 
classes implementing this interface Is the same as forthe ContentHandler mechanism used in java.net.URL. 

class CommandMap: The CommandMap class provides an interface to the registry of viewer, editor print etc 
objects available in the system. Developers are expected to either use the CommandMap implementation ind'uded 
with this package (MailcapCommandMap) or develop their own. Note that some of the methods in this class are 
abstract. 

interface CommandObject: Beans that are Activation Frameworic aware implement this interface to find out which 
command verb they're being asked to perform, and to obtain the DataHandler representing the data they should 
operate on. Beans that dont implement this interface may be used as well: Such commands may obtain the data 
using the Externalizable interface, or using an application-specific method. 

class Commandlnfo: The Commandlnfo dass is used by ComnrandMap implementations to describe the results of 
command requests. It provides the requestor with both the vert) requested, as well as an instance of the bean. 
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There is also a method that will return the name of the class that implements the command but it is not guaranteed 
to return a valid value. The reason for this is to allow CommandMap implmentations that subclass Commandlnfo to 
provide special behavior. For example a Framework Deliverables 

5 JAF Framework Auxiliary Classes 
[0053] 

class FileDataSource: The FileDataSource class implements a simple DataSource object that encapsulates a file. 
10 It provides data typing services via a RIeTypeMap object. 

class RIeTypeMap: The RIeTypeMap is an abstract class that provides a data typing interface for files. Implemen- 
tations of this class will implement the getContentType methods which will derive a content type from a file name 
or a File object. FileTypeMaps could use any scheme to determine the data type, from examining the file extension 
15 of a file (like the MimetypesFileTypeMap) to opening the file and trying to derive its type from the contents of the 

file. The FileDataSource class uses the default FileTypeMap (a MimetypesFileTypeMap unless changed) to deter- 
mine the content type of files. 

class MimetypesFileTypeMap: This class extends FileTypeMap and provides data typing of files via their file exten- 
20 sion. It uses the .mime .types format, class URLDataSource: The URLDataSource class provides an object that 
wraps a URL object in a DataSource interface. URLDataSource simplifies the handling of data described by URLs 
within the JavaBeans™ Activation Framework because this class can be used to create new DataHandlers. 

class MailcapCommandMap: MailcapCommandMap extends the CommandMap abstract class. It implements a 
25 CommandMap whose configuration is based on mailcap files (RFC 1 524). The MailcapCommandMap can be con- 
figured both programmatically and via configuration files. 

class Activation. DataFlavor: The ActivationDataFlavor is a special subclass of java.awt.datatransfer.DataFlavor. It 
allows the JAF to set all three values stored by the DataFlavor class via a new constructor as well as improved 
30 MIME parsing in the equals method. Except for the improved parsing, its semantics are identical to that of the JDK's 
DataFlavor class. 

class UnsupportedDataTypeException: Signals that requested operation does not support the requested data type. 
35 class MimeType: A Multipurpose Internet Extension (MIME) type, as defined in RFC 2045 and 2046. 
Small Footprint Device Application/Service Containment Framework 

[0054] As described above, the bookmark service or another application/service running on a small footprint 
40 device, such as a personal contact list service, may invoke a separate service module to perform an action selected by 
a user for a particular data source. Since the system may open-ended, allowing various actions to be defined for various 
types of data sources, it may be necessary or desirable for the small footprint device software applications/services to 
, be based on a modular, extendable, lightweight application/service containment framework. Such a containment frame- 
work is described below. 

45 

Figure 5 - Hardware Architecture Block Diagram 

[0055] Figure 5 is a block diagram illustrating the hardware architecture of a typical small footprint device. As used 
herein, a small footprint device is a hardware device comprising computing resources such as a processor and a sys- 

50 tem memory, but having significantly greater constraints on one or more of these resources than a typteal desktop com- 
puter has. For example, a small footprint device may have two megabytes of memory or less, whereas a typical desktop 
system may have 64 megabytes or more. Also a typical small footprint device may have significantly less processing 
power than a typbal desktop computing system, either in terms of processor type, or processor speed, or both. For 
example, a personal data assistant device may have a 16 MHz processor, whereas a typical desktop system may have 

55 a processor speed of 100 MHz or higher. Also, a typical small footprint device may have a display size significantly 
smaller than the display screen of a desktop computing system. For example, the display screen of a handheld compu- 
ter is typically small compared to the display screen of a desktop monitor. 

[0056] It is noted that the specific numbers given are exemplary only and are used for comparison purposes. For 
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example, a personal data assistant having eight megabytes of memory or more may still be a small footprint device 
although the dewce has more memory than the typical figure of two megabytes given above. 

[0057] Small footprint devices may also have constraints on other resource types compared to typical desktop com- 
puting systems, besides the memory, processor, and display size resources described above. For example a typical 
small footprint device may not have a hard disk, may not have a network connection, or may have an interm'ittent net- 
work connection, or may have a wireless network connection, etc. 

[0058] Many small footprint devices are portable and/or are small compared to desktop computeis but are not nec- 
essanly so. Also, many small footprint devices are primarily or exclusively battery-operated. Also, small footprint devices 
may typically have a more limited or narrow range of usage possibilities than a typical desktop computing system Small 
footpnnt devtees include, but are not limited to. the following examples: handheld computers, wearable devtees (e g 
wnstwatch computers), personal data assistants (PDAs). 'smarT cellular telephones, set-top boxes, game consoles' 
global positioning system (GPS) units, electronic textbook devices, etc. Since new classes of consumer devtees ar^ 
rapidly emerging, it is not possible to provide an exhaustive list of small footprint devices. However, the term "small foot- 
pnnt device- IS intended to include such devices as may reasonably be included within the spirit and scope of the term 
as described above. 

[0059] Rgure 5 illustrates a block diagram of a typical small footprint device. It is noted that the small footprint 
device may have various different architectures, as desired. The hardware elements not necessary to understand the 
operation of the present invention have been omitted for simplicity. 

[0060] As shown in Rgure 5. the small footprint device contains a processor 1 00. The processor 1 00 may be any 
of vanous types, including an x86 processor, e.g., a Pentium class, a PowerPC processor, as well as other less powerful 
processors or processors developed specifically for small footprint devices. The processor 1 00 may have various clock 
speeds, including clock speeds similar to those found in desktop computer-class processors, as well as lower speeds 
such as 1 6 MHz. 

[0061] Also shown in Rgure 5 the device includes a system memory 1 02. The system memory 1 02 may comprise 
memory of various types including RAM or ROM. A typical small footprint device may have a very small memory stor- 
age capacity compared to a typical desktop computer system. 

[0062] A small footprint device may also comprise one or more input mechanisms. An input mechanism 104is illus- 
trated in Figure 5. The input mechanism 104 may be any of various types, as appropriate to a particular device For 
example, the input mechanism may be a keypad, mouse, trackball, touch pen. microphone, etc. 
[0063] A small footprint device may also comprise one or more display mechanisms. A display 1 06 is illustrated in 
Figure 5. However, a small footprint device may not comprise a display, or may comprise another type of output mech- 
anism, such as an audio speaker. The display mechanism 1 06 may be any of various types, as appropriate to a partic- 
ular device. The display mechanism for a typical small footprint devfce, such as a smart cellular phone, may be small 
compared to the display of a desktop computer system. 

Figure 6- Hardware/Software Hierarchy Diagram 

[0064] Rgure 6 Illustrates a typical hierarchy of hardware/software layers involved in a system running applications 
and services within the containment frameworie The drawing is exemplary, and various layers may be added, com- 
bined, or omitted as appropriate for a particular device or implementation. 

[0065] The base layer shown in Rgure 6 is the device hardware layer 120, which comprises the hardware 
resources necessary to support a software system, such as a processor and system memory. In one embodiment the 
hardware of a small footprint device, such as the small footprint devfce hardware example illustrated in Rgure S imple- 
ments the hardware layer 120 illustrated In Rgure 6. However, in other embodiments, the hardware layer 120 may be 
implemented in other types of devices, such a device with even greater resource constraints than a typical small foot- 
print device, such as a smart card. 

[0066] As shown in Rgure 8, the next layer up from the hardware layer Is the operating system layer 122 As is well 
known in the art, the operating system functions as an interface layer between the device hardware and software run- 
ning on the device and serves as a manager for low-level tasks such as Input/output, memory management etc The 
operating system 122 illustrated in Rgure 6 may be any particular operating system which supports the higher layers 
shown in Figure 6. The operating system 1 22 may be a small and efficient one that is suitable for or written parttoularly 
for use in a small footprint device. For example, the operating system 122 may be the JavaOS operating system avail- 
able from Sun Mterosystenns, Inc. 

[0067] In one embodiment, the containment framework is implemented in a Java™ application environment as one 
or more Java™ classes. As shown in Rgure 6. the Java™ virtual machine layer 1 24 and Java™ application programming 
interface (API) class libraries layer 126 are the next layers up from the operating system. These two layers together 
masa up the Java™ application environment, or Java™ platfonm. Classes implementing the containment framework may 
be built using the Java™ libraries 126 and compiled into bytecodes. The bytecodes are instructions which execute on 
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the Java™ virtual machine 124, which interacts with the operating systenn 122 and/or the device hardware 120. 
[0068] In one embodinnent, the containnnent framework is implemented in the PersonaUava Java™ application envi- 
ronment, which is a Java™ platfomn designed to be highly scalable, modular, and configurable, while requiring minimal 
system resources. PersonaUava™ comprises the Java™ virtual machine and a subset of the Java™ API, including core 

5 and optional APIs and class libraries. In addition, the PersonaUava™ API includes specific features required by con- 
sumer applications in resource-limited environments, such as a specialized version of the Java™ abstract window toolkit 
(AWT). The PersonaUava™ AWT library is targeted and tuned for consumer product look and feel, providing graphics 
and windowing features while supporting low-resolution displays and alternate input devices (via an extended event 
model for mouse- and keyboard-less devices). 

10 [0069] Refen^ing again to Figure 6, the containment framework 128 is shown as the next layer up from the Java™ 
platfonn layer. As noted above, the containment framework 128 may also be based on other platfomns. As described in 
detail below, the containment framework 128 manages program modules, e.g. by enabling module registration, lookup, 
instance tracking, etc. Modules may provide various services. The containment framework 128 enables modules to 
request other modules, in order to use their services. Applications may be implemented as modules that utilize the serv- 

15 ices of other modules. The containment framework 1 28 thus provides a lightweight, extendable service and application 
framework, enabling applications to coexist and share a modular code base. 

[0070] This type of extendable architecture enabling multiple program modules to cooperate is an important devel- 
opment for small footprint devices. Small footprint devices have historically been limited to relatively narrow uses. For 
example, cellular phones were typically used for telephony and little else. However, as various technologies are devel- 

20 oped allowing small footprint devices to become "smarter**, having general-purpose processors, larger display screens, 
etc., it has become desirable to expand the scope of applications used in small footprint devices. 
[0071 ] The present containment framework may enable the types of applications and services generally associated 
with desktop computing environments to work together in a small footprint device, in a manner that desktop computer 
users are familiar with. As illustrated in Rgure 6 and described above, services and applications 130 running on a small 

25 footprint device may be implemented as modules built on the containment framework layer 128. For example, the Per- 
sonal Applications suite available from Sun Mterosystems, Inc. is built using one embodiment of the containment frame- 
work 128. The Personal Applications Suite comprises an integrated set of applications such as a browser, an enriail 
client, and a personal organizer. 

[0072] Figure 6 also illustrates the ability of some embodiments of the containment framework 1 28 to integrate off- 
30 device services 132 with on-device applications/services 130. For example, the containment framework 128 may pro- 
vide an interface between a small footprint device and a network such as a Jini network. A small footprint device system 
may register its servk^es for use by other devces or clients in a network. The containment framework may also enable 
services and applications within the small footrpint device to look up and use services provided by other network 
devices. The integration of services of the small footprint device with network services is discussed in more detail below 
35 for Figure 7. 

Figures 7-11: Exemplary Network Device and Service Federation 

[0073] Rgure 7 illustrates an exemplary network in which a small footprint device running applications/services in 
40 the containment framework is connected to a local service-based network. In the example shown, a smart cellular 
phone 134 utilizing the containment framework 144 is connected to the network. Also shown attached to the network 
are a printer 130 and an internet-enabled television 132. In this example, it is assumed that the printer 130 and televi- 
sion 132 devices are operable to export services to a network and possibly use the services of other devtees on the 
network. For example, the printer may export its print service 1 38, and the internet television may look up the print serv- 
45 ice and use it to print a web page. To facilitate the federation of devices and services in this manner, a lookup service 
136 is located on the network The lookup service 1 36 may reside on a separate device such as a network server. 
[0074] The federation of devices and services may be implemented in various ways. For example, Jini™ technology, 
available from Sun Microsystems, Inc., comprises components and a programming model which enables the type of 
distributed system illustrated in Rgure 7. In one embodiment, the local network shown in Figure 7 may be a Jini™ net- 
so work, and the printer 130 and internet television 132 may be Jini™-enabled devices. Each device is operable to find the 
Jini™ network lookup service and register the services it offers with the lookup service. The lookup service maps inter- 
faces indicating the functionality provided by a service to sets of objects that implement the service. 
[0075] To add its services to a service federation, a device or other service provider may first locate an appropriate 
lockup service by using a "discovery" protocol. Rgure 8 illustrates the discovery process. As shown, the service pre- 
ss vider 1 64, e.g. the printer 130 shown in Figure 7, may broadcast a request on the local network for any lookup services 
to identify themselves. 

[0076] Once the service provider 1 64 has located the lockup service 1 60, the service provider 1 64 may register its 
service with the lookup service 1 60 by using a "join" protocol. Figure 9 illustrates the join process. The service provider 
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1 64 may create a service object which clients can use to invoke the service. As illustrated in Rgure 9, the service object 
for the provided services may then be loaded into the lockup service 160. along with service attributes or descriptors 
containing information about the types or names of services provided. For example, in a Jini™ networic, the printer 130 
shown in ngure 7 may create a service object which comprises a Java™ programming Interface for the print service 
1 38. The pnnter 1 30 may then call a 'register method of the lookup service 1 36. passing this service object along with 
attributes which specify that the service 138 being registered Is a print service, the printing resolution, the possible 
paper sizes, etc. 

[0077] Once the service provider 1 64 has joined its services with the lookup service 1 60. other networic clients m^ 
request and use the servfces. The process of requesting a service, called lookup, is illustrated in Figure 10 After dis- 
covering the lookup service, a client 1 62 may request a service from the lookup service 160 using a description of the 
requested service. The lookup service 1 60 attempts to match the description given by the requestor to the servtees that 
have joined the lockup service. The lookup service 1 60 may use the servtee attrtoutes sent by the service provider 1 64 
dunng the join process to perfomi this matching. If a match is found, the lockup service 160 provides the appropriate 
service object to the client 1 62. For example, a Java™ interface for the requested service may be provided to the client 
1 62, 

[0078] Once a client 1 62 has received a service object from the lockup service, the client may invoke the service 
Rgure 1 1 illustrates the process of service invocation. When a service is invoked, the client 162 and the service pro- 
vider 1 64 may communicate directly with each other. Any of various interaction protocols may be used for this commu- 
nication. For example, the protocol used may be Java™ Remote Method Invocation (RMI), CORBA. DOOM, etc The 
sen/ice object that a dient receives from the lookup service may call back to code located at the service provider e g 
by calling an RMI method, or it may execute locally to provide the requested service, or it may use a combination of 
these approaches. 

[0079J As shown in Rgure 7, the lockup service 136 for a local networi< may also act as a gatew^ to an outside 
networic such as the Internet 54. The service-based distributed computing model may thus be extended to include cli- 
ents and sen/ices located outside the local networic For example, the technology being developed for the Open Service 
Gateway Initiative (OSGI) may be leveraged to implement this type of distributed computing system. 
[0080J This type of service sharing between and across different networks and the Internet may enable new types 
of applications to be developed. For example, merchants may use Internet services to record data about specific con- 
sumers, and advertising servce providers may use this data to push context-specific ads onto consumer devices 
depending on which tocal network the device is connected to. etc. For example, a customer may enter a shopping mal'l 
and connect a personal data assistant (PDA) into a local networic for the shopping mall, via a wireless connection An 
Internet-based consumer data service may be joined with the lookup service for the shopping mall networic and m^ 
provide information about the specific consumer who has just plugged into the mall networic Services running in the 
shopping mall network may then use this data together with other factors such as the customer's current location within 
the mall, the time of day. etc., in order to generate personalized ads and push them onto the customer's PDA. 
10081] Many other examples of services based on the network of Rgure 7 are possible. For example- network-ena- 
bled consumer devices within a home may utifize a service provided by a power company, via the Internet, which man- 
ages power consumption within the home; security service providers may monitor a home or specific devices via 
network services and may notify the owner immediately when property is broken Into; health servfce providers may 
remotely monitor a patient's state by communicating with medical instruments; etc. 

[0082] In the examples listed above, an assumption is made that devices are able to transparently connect to a net- 
work, integrate network services with device-resident services, and export device-resident services for use by networic 
clients. The containment framework described herein may provide the necessary interface to integrate services and 
applications of small footprint devices such as personal data assistants, handheld computera. smart cellular phones 
etc. with a network service federation. 

[0083] As shown in Figure 7 and described in more detail below, the containment frameworic 144 has its own type 
of lookup service 1 46. The lookup service 1 46 within the containment framework 1 44 may operate similarly to the local 
networic lookup service described above, utilizing discovery, join, lookup, and service invocation processes For exam- 
ple, the personal organizer application 152 may utilize various services such as a calendar service a contact list serv- 
ice, a bookmaric service, etc. (not shown). The personal organizer application 152 may obtain a reference for 
communicating with these services via the containment frameworic lookup service 146. 

[0084] The containment frameworic 1 44 may integrate its own lockup service 1 46 with an off-device lookup servtee 
such as the local network lookup service 1 36 shown in Rgure 7. In this way, off-device services such as the print servtee 
1 38 and the web service 140 may become available to the applications/services 1 48. 1 50. and 1 52 of the containment 
framework, and vice versa. For example, the personal organizer application 152 may request a print service from the 
containment framework lockup servtee 1 46. The containment frameworic lookup service 1 46 may first search for an on- 
device pnnt service. If one is not found, the containment framework lookup service 1 46 may then request a print servtee 
from the network lookup service 1 36. The service object for the print service 1 38 may then be returned to the personal 
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organizer 152. An interface 142 between the on-device services/applications and the off-device services is illustrated 
in Figure 7. Details follow on how the integration of on-device/off-device services may be implemented. 
[0085] As noted above, clients of services may themselves be services to other clients. For example, the email cli- 
ent "application" 150 of the smart cellular phone shown in Figure 7 may itself be a service to a client running in the con- 

5 tainment framework 144 or to a network client. For example, in the case of malfunction, the printer 130 shown in Figure 
7 may request an email service so that it can send diagnostic infomnation to a service technician, if the network Lookup 
service 136 cannot find a network-based email service, it may request an email service from the smart cellular phone 
134 via the interface 142, A service object for the email application/service 150 running in the containment framework 
144 may be passed to the requesting printer client 130, In this example, the printer client 130 may communicate directly 

10 with the email application/service 150 to send an email containing diagnostic information to a printer servtee technician. 
The email application/service 150 may send the email immediately if it is able to find an email server service, or it may 
send the email later when such a service becomes available when the cellular phone user connects to a different net- 
work. 

[0086] Although the above description references specific protocols and programming models, such as Jini^ tech- 
15 nology, it is noted that these specific technologies are exemplary only. For example, the applications and services within 
the containment framework may be integrated with clients, services, devices, networks, etc. which employ any of vari- 
ous types of standards, protocols, and programming models, including, but not limited to: Jini™, CORBA, COM/DCOM, 
Bluetooth, CAU CEBus, HAVi, Home API, HomePNA, HomePnR HomeRF. VESA, etc. 

20 Figure 12 - Containment Framework Block Diagram 

[0087] Figure 1 2 is an abstract block diagram illustrating the basic architecture of the containment framework envi- 
ronment. As described above, the containment framework provides a containment system for applications and serv- 
ices. These applications and services are managed within the system as units called modules. The containment 

25 framework is lightweight; in one embodiment, modules may interact with a single framework manager object which per- 
forms alt module management. This manager is referred to herein as the central framework instance. In one embodi- 
ment, the central framework instance may be implemented as an instance of a Java™ class. Figure 12 illustrates the 
central framework instance 170 and the code and data it comprises/manages. It is noted that Figure 12 illustrates one 
embodiment of the containment framework. Other embodiments may employ a different architecture and/or may be 

30 implemented in different programming languages or software environments. For example, the module manage- 
ment/containment performed by the central framework instance 170 illustrated in Figure 12 may be performed by mul- 
tiple objects or components in other embodiments. 

[0088] As shown in Figure 12, the central framework instance 170 comprises data 182 representing the modules 
currently loaded in the system. The containment framework architecture is non-hierarchical. Thus, the loaded modules 

35 may be represented as a flat list or array of modules. This non-hierarchical system helps to keep the core containment 
framework code and the modules running within the framework compact. Systems employing hierarchical components 
such as JavaBeans™ components may provide associated benefits, but the benefits come at the expense of a more 
complex management system requiring more system resources. However, the containment framework does provide a 
mechanism for the non-hierarchical modules to gain many of the benefits of a hierarchical containment system. This 

40 mechanism is described below for Rgures 13 and 14. 

[0089] As shown in Figure 1 2, in one embodiment the central framework instance 1 70 comprises publicly accessi- 
ble methods 1 78 which modules may call. These methods may be broken Into abstract groups. For example, one group 
of methods 172 may comprise lookup methods. Lookup methods implement the lookup service functionality described 
above. Modules may pass a module descriptor to a lookup method of the central framework instance 170 to locate a 

45 particular service module. The containment framework lookup process is described below for Figure 1 6, Another group 
of framework methods 174 may comprise methods for loading and unloading modules. After finding a service module, 
a client module may request the central framework instance 170 to load the service module and return a reference to 
the loaded module. The client module may then invoke the service. The client may call a framework method to release 
the service module when it is finished using it. Although described as distinct groups, the division of methods into 

so lookup and load/unload groups may be only a conceptual division. For example, in one embodiment a lookup method 
may also load a module that it matches and return a reference to the matched module. 

[0090] Figure 1 2 also illustrates system data 1 80 referred to as framework metadata, whbh may comprise data 1 82 
describing the list of loaded modules and other data describing the state of the system. Another abstract group of meth- 
ods 1 76 of the central framework instance 1 70 may comprise reflection methods. Reflection methods are somewhat dif- 
55 ferent than the other groups of methods since they provide direct access to the core metadata 180: A special class of 
modules called system modules may call reflection methods to gain access to the metadata 1 80. Regular modules may 
not access the metadata 1 80. 

[0091] After receiving a reference to the core system data 1 80, a system module may use or modify the data in any 
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way desirable. Thus, the containment framework is highly extendable. The central framework instance 170 may itself 
remain small, and system modules may be added to implement any functionanty not already enabled by the central 
framework instance 170. For example, a system module may enable the integration described above for Rgures 7-11 
between applications/services running within the containment framework and services based in an extemal network. 
[0092J In this example, such a system module may be written as a secondary lookup service that conforms to the 
protocols and programming model of the extemal network. For example, for a Jini™ network, a system module may be 
wntten which discovers the Jini™. network lookup service and joins the network lookup service, registering itself as a 
secondary lookup service. When a network client requests a service, the network lookup service may invoke the lookup 
service implemented by the system module. This system module may attempt to find a service module within the con- 
tainment framework whteh matches the description of the requested seivlce, if a match is found, then the system mod- 
ule may perfomn any necessary steps to export the service module to the network client, since the system module has 
full access to the system module list and metadata. For example, the system module may load and register the matched 
service module into the system and return an interface, such as a Java™ interface, to the newly loaded module to the 
requestor. 

nqures 13 and 14- Simulatino a Hipmmhi™! Fnvlmnm^nt 

[0093] It IS often desirable to establish a hierarchical context for modules. For example, several service modules of 
the same type may be present in a system, but each may behave sfightly differently. In a hierarchical containment sys- 
tem, a request by a module for a service may be filtered through a parent or containing module of the requesting module 
so that a reference to a specific servfce module may be passed back to the requestor. Hierarchteal containment also 
has other inherent advantages, such as an ability to easily distribute and store data among a hierarchy of modules 
However, as stated above, a fill implementation of a hierarchical containment system may be very costly in terms of the 
system resources required, such as memory and processing power. TTie containment framework may provide a mech- 
anism giving developers and applications many of the benefits of hierarchical containment, but without the high over- 
head costs usually associated with it 

[0094] For example, one embodiment of the containment framework allows modules to register themselves as 
module request listeners of other modules. For example, a module A may register itself as a request listener of a mod- 
ule B, e.g., by calling an AddRequestListener method of the central framework instance. When module B subsequent^ 
calls a method of the central framework instance to find a particular service, the central framework instance checks for 
any module request listeners for module B. In this case, it finds module A as a request listener, and asks module A to 
provide the requested servk:e module to module B. 

[0095] Figures 13 and 14 illustrate an exemplary use of module request listeners in the containment framework 
Rgure 13 illustrates a desired conceptual module hierarchy for print services. As shown in the figure, two print service 
modules 1 92 and 1 94, print service A and print service B, are encapsulated in a print manager module 1 90 For exam- 
ple, rhe two pnnt services 192 and 194 may print to different locations, have different resolution and color capabilities 
etc. Either of these print service modules may satisfy a lookup request made by another module for a print service' 
However, it may be desirable to employ a print manager module whteh selects and returns a particular print service For 
example the pnnt manager 1 90 may select a print service based on which client module makes the print request or the 
print manager may display a dialog box asking for user input for the desired print service characteristics. 
[0096] Although the containment framework utilizes a non-hierarchteal containment model, the hierarchy illustrated 
in Rgure 13 may be realized by registering the print manager module 190 as a module request listener of client mod- 
ules that may request a print service. Figure 14 Illustrates example modules 198 which may run in a system As 
descnbed eariier, these modules may themselves employ other modules as services. According to the non-hierarchical 
model of the containment frameworic, the modules are shown an^nged in a flat layout, with no inherent module hierar- 
chy. 

[0097] In this example, the web browser module 1 96 may be operable to make a print request, e.g , for printing a 
web page. As shown in Rgure 14, the print manager module 1 90 may be registered as a module request listener for 
the web browser module 196. Upon receiving the print service request from the web browser 196, the containment 
frarnework lookup service may find the print manager module 190 registered as a request listener for the web browser 
module 1 96 and may ask the print manager module 1 90 to provide a print service module to the web browser requestor 
1 96 The pnnt manager module 1 90 may then return a reference to print service module A 1 92 or print service module 
B 1 94, or the pnnt manager module 1 90 may present a dialog box to the user to decide which print service module to 
return, etc. Thus, the desired module hierarchy of Rgure 13 may be implemented for non-hierarchical modules of the 
containment framework. 
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Figure 15 - Parcel Packaging Units 

[0098] Modules may be packaged into units referred to as parcels. This packaging serves several purposes. For 
example, parcels provide a convenient mechanism to manage related code and data as a unit. If closely related mod- 
5 ules have static dependencies, then they may be packaged together Into a parcel. Parcels may be used to handle instal- 
lation and upgrading within a system. 

[0099] Figure 15 Illustrates an example parcel 200 that groups together modules related to a personal information 
manager (PIM). The figure shows a calendar module 202, a contact list module 204, an appointment module 208, and 
a user Interface module 206. Various other modules may be present in the parcel as desired. The modules of the PIM 
10 parcel 200 may also make use of various core sen/ice modules running within the containment framework, such as 
bookmark services, find services, etc. The use of a PIM parcel may simplify installation and upgrading of a PIM appli- 
cation. Packaging the PIM modules into a parcel in this way also has the development-time benefit of creating separate 
code units for multi-target development. 

[0100] Parcels also provide an additional way to provide a run-time context for non-hierarchical modules. When a 
15 module is loaded into the system, the central framework instance may store metadata specifying which parcel, if any, 
the module belongs to. Sen/ice modules may later use this information to provide services differently for different client 
modules, depending on which parcel the client belongs to. For example, client modules may use a file access service 
module to obtain a root directory. The file access module may return different root directories for different clients, 
depending on which parcels the clients belong to. ' 

20 

Rgure 16 - Module Request Flowchart Diagram 

[0101 ] Figure 1 6 is a flowchart diagram illustrating a typical lookup process that the central framework Instance may 
perform when it receives a lookup request for a service module from a client module. It is noted that Figure 16 is exem- 
25 plary and that various steps may be combined, omitted, or modified. For example, as noted previously, system modules 
may be added which customize the lookup process. 

[0102] In step 300 of Rgure 16, the central framework instance receives a module lookup request from a requestor 
module. For example, the requestor module may call a RequestModule method of the central framework instance, 
passing a module descriptor for the service module being requested, as well as a reference to the requestor module 

30 itself. The reference to the requestor module may be added to the system data so to keep track of servfce module users. 
As described in more detail below, a module may be unloaded when no other modules are using it. 
[0103] The module descriptor passed by the requestor module specifies various attributes about the requested 
module that the framework instance can use to attempt to find a matching module. This module descriptor may be an 
object which comprises information such as the requested module's service type, class name, and/or service-specific 

35 attributes, etc. The requestor may also pass a text description to the central framework Instance, which the central 
framework instance may use to create a module descriptor object. 

[0104] In step 302, the central framework instance checks to see whether any request listener modules are regis- 
tered for the requesting module. If a request listener is found, then in step 304 the framework instance notifies the 
request listener of the request and Instructs the request listener to attempt to provide a module which matches the mod- 
40 ule request descriptor. If the request listener can provide a matching module, then execution proceeds to step 31 4. Oth- 
erwise, other registered request listeners may be asked to provide a module, until a rriatch is found or there are no more 
request listeners. 

[0105] If no request listeners are found, or if no request listeners can provide the requested module, execution pro- 
ceeds to step 306. However, in one embodiment, if one or more request listeners are registered for the requesting mod- 
45 ule, and none of them are able to provide a matching module, then execution may stop after step 304. In step 306, the 
central framework Instance checks the list of modules to determine whether one of the modules matches the module 
descriptor. If a match is found, then in step 308 the framework instance checks whether the matched module is multi- 
instantiable. If not, then execution proceeds to step 314. 

[0106] If the matched module is found to be muiti-instantiable in step 308, then the central framework Instance may 
50 continue to search through the module list for a match. If there are no more modules to search, execution proceeds to 
step 310. In step 310, the framework Instance searches for module-provider modules in the module list Module-pro- 
vider modules are modules capable of providing a requested module. For example, a network lookup service may be 
Imported as a module-provider module for the containment framework. 

[0107] If a module-provider module is found, then in step 312, the central framework instance notifies the module- 
55 provider module of the request and instructs it to attempt to provide a module which matches the module request 
descriptor. If a match is found then execution proceeds to step 314. If the module provider cannot provide the requested 
module, the central framework instance may search for other module-provider modules and repeat step 312. If no mod- 
ule providers are present in the module list or If none can provide the requested module, then the requestor is notified 
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that the request cannot be futfilled, and execution completes. 

[0108] Step 314 may be reached from step 304, 308. or 312. In all cases, a module Is found which matches the 
module request descriptor. In step 314 the requestor is registered as a user of the matched module, and in step 31 6 a 
reference to the matched module is retumed to the requestor. Any necessary initialization steps involved in loading and 
tnitialEing the matched module are also performed in step 314. For example, modules may have an Initialize method 
that IS called when a module is loaded. 

[0109] As noted above, the flowchart of Rgure 16 is exemplary, and various embodiments may have different 
lookup/load scenarios. For example, a module may call a central framework method to load a service module without 
retuming a reference to the matched module, or request listeners may be ignored in some cases, etc. 

Rgure 17 - Module Release Flowchart Diag ram 

[01 10] When a client module is finished using a service module, the client may call a method of the central frame- 
work instance to release the module. Rgure 1 7 is a flowchart diagram illustrating the module release process The flow- 
chart of Rgure 1 7 is exemplary, and various steps may be combined, omitted, added, or modified as required or desired 
for different embodiments. 

[0111] In step 330. the central framework instance receives a module-release notice from a user module As 
descnbed above for Rgure 16, when a user module requests a service module, the user module is added to a list of 
users of the service module. In step 332, the central framework Instance removes the releasing user module from the 
20 list of users of the released module. In step 334. the framework instance determines whether any other user modules 
are using the released module, e.g., by checking whether other modules are present in the releases module's user 
module list. If so, then execution stops. 

[0112] If no other modules are using the released module, the central framework instance may attempt to unload 
the released module. In step 336, the framework instance may call a CanRnalize method of the released module The 

25 CanRnalize method retums true if the module can be unloaded, or false otherwise. If the CanRnalize method returns 
false in step 336. then execution stops. Othenvise, a Rnalize method of the released module may be called The Final- 
ize method may perfom any necessary steps for unloading the module, such as releasing resources. The module may 
then be unloaded, which may involve garbage-collection, etc., depending on the particular embodiment. 
[0113] Although the present invention has been described in connection with specific embodiments it is not 

30 intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such alternatives 
modifications, and equivalents, as can be reasonably included wrthin the scope of the invention as defined by the 
appended claims. ' 
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Claims 

1 . A system for creating persistent references to data sources comprising: 

a small footprint device, wherein said small footprint device includes a processing unit and system memory; 
a software framework stored in said system memory, wherein said software framework supports program mod- 
ules, wherein said program modules implement computing services; 

a first computing service implemented by one or more of said program modules, wherein said first computing 
service is operable to create a persistent reference to a data source in response to a user selecting said data 
source. 

a second computing service implemented by one or more of said program modules, wherein said second com- 
puting service is operable to access said data source using said persistent reference. 

2. The system of claim 1 . further comprising an activation framework operable to create an entity encapsulating said 
data source; wherein said persistent reference created by first computing service references said entity encapsu- 
lating said data source. 

3. The system of claim 2, wherein said activation framework is further operable to invoke said second computing serv- 
ice to perform an operation on said data source. 

4. The system of claim 3, wherein said activation framework is the JavaBeans Activation Framework. 

5. The system of any preceding claim, wherein said software firework requires less than 300 kilobytes of memory. 

6. The system of any preceding claim, wherein the small footprint device is a small footprint device from the group 
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consisting of: personal data assistant (PDA), cellular phone, and global positioning system (GPS) receiver. 

7. The system of any preceding claim, wherein the small footprint device is a small footprint device from the group 
consisting of: game console, wearable computing device, set-top box, and electronic bool< device. 

5 

8. The system of any preceding claim, wherein the small footprint device comprises less than 2 megabytes of mem- 
ory. 

9. The system of any preceding claim, wherein said small footprint device comprises a display screen smaller than 
10 twenty square inches. 

10. The system of any preceding claim, wherein said small footprint device is exclusively battery operated. 
11-. A method of creating persistent references to data sources comprising: 

15 

providing a small footprint device that includes a processing unit and system memory; 

storing a software framework in the system memory, wherein the software framework supports program mod- 
ules that implement computing services; 

in response to a user selection of a data source, creating a persistent reference to the service implemented by 
po one or more of said program modules; and 

accessing said data source using said persistent reference by means of a second computing service imple- 
m^ed by one or more of said program modules. 
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